From ed2a5cde8d36b48e75f59fead8da5815b8613413 Mon Sep 17 00:00:00 2001 From: "kaf24@firebug.cl.cam.ac.uk" Date: Tue, 30 May 2006 18:11:34 +0100 Subject: [PATCH] Fix infinite recursion loop in get_page_type() error path. Signed-off-by: Keir Fraser --- xen/arch/x86/mm.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index cc596a6990..29e72dea30 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1598,12 +1598,18 @@ int get_page_type(struct page_info *page, unsigned long type) { if ( unlikely((x & PGT_type_mask) != (type & PGT_type_mask) ) ) { - if ( current->domain == page_get_owner(page) ) + if ( (current->domain == page_get_owner(page)) && + ((x & PGT_type_mask) == PGT_writable_page) ) { /* * This ensures functions like set_gdt() see up-to-date * type info without needing to clean up writable p.t. - * state on the fast path. + * state on the fast path. We take this path only + * when the current type is writable because: + * 1. It's the only type that this path can decrement. + * 2. If we take this path more liberally then we can + * enter a recursive loop via get_page_from_l1e() + * during pagetable revalidation. */ LOCK_BIGLOCK(current->domain); cleanup_writable_pagetable(current->domain); -- 2.30.2